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ABSTRACT 


This thesis is a detailed design of a security xernel 
for an archival file storage system. Microprocessor 
technology is used to address a major part of the problem 
Dolor ormaylon security in a distributed computer system. 
Wii lizine multiprogramming techniaues for processor 
Ei lcienty, seszmentatlon for controlled sharing, and a 
mooe-tree Structure for avolding intermodule dependencies, 
the Archival Storage System is designed for implementation 
on the Zilog Z8¢@@1 microprocessor with a memory management 
ünit. The concepts ofa mT orocess structuüure and a 
distributed kernel are used in providing management of the 
shared hardware resources of the system. Tke security 


kernel primitives create a virtual machine environment and 
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provide information Security accordance Sw a 


aom- dadn Sseretionary security policy. 
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DTN TRODUCEION 


This detailed design of a security kernel provides a 
basis for implementation of an archival file storage 
operating system. The system is intended to store rhes 
for an array of computer hosts at multiple information 
security levels. The design presents algorithms and data 
structures which can be implemented on microprocessor 
hardware available today, to provide economical and secure 
storage. Controlled sharing of information and multilevel 
security were the kKey design goals. Multiprogramming is 
the technique used to improve efficiency of the system 
which is primarily performing input and output operations. 
A loop-free structure is used to avoid undesirable 
dependency loops [1]. This allows modules to be changed 
without introducing changes in other modules. 

There are two components of the Archival Storage 
System: 1) the Supervisor and 2) the Security Kernel [2]. 
The Supervisor (the subject of separate research [3]) 
EI OR ls all User services: 1) hierarchical file system, 
ERR discretionary access controls, and 3) protocols for 
communication. The Supervisor operates outside the Kernel 
domain on a virtual machine created by the Kernel 
primitives. The Supervisor’s privilege-restricted domain 
has access only to a subset of the machine instructions, 
thus needing the Kernel primitives to accomplish tasks 
sen as input Or outout. 


The Security Kernel described in this thesis manages 
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the real resources of the hardware system: 1) memory, 2) 
microprocessor, 3) external devices, and 4) input/output 
Morts. It is also responsible for mediating all 
non-discretionary access to information. “The Kernel 
Operates in the most privileged domain of tne machine and 


therefore has access to all machine instructions. 


A. BACKGROUND 

Microprocessors have become affordable, prolific, and 
powerful computing resources. The result of these 
attributes is the use of nicroprocessors in applications 
previously requiring much larger and more expensive 
Brocessors. Additionally, new applications which can now 
be economically computerized are being seriously explored. 

Conversely, software has become more costly. 
Microprocessor operating systems and applications programs 
continue Lo pe nighiy specialized, thus  falllsg to 
Medsonably exploit the potential of the microprocessor. 
The specialization of software for microprocessors also 
pervetuates problems such as I/O format incompatibilities 
which occur when information exchange among processors is 
Reis Pe 

Information seemrity on microprocessors hes been 
completely iomored o to date, or handled with ad-hoc 
attempts at a solution. However, this issue is becoming 
increasingly important as the uses of microprocessors 
continue to be expanded. For example, the Department of 


the Navy is irvestizating the use of microprocessors on 


al 





small ships for automating shipboard administrative 
Pumetions [4]. Information security for such functions is 
a major requirement which cannot presently be met. 
Proposing a solution to the above problems, a 
wen level design for a secure operating system for 
microprocessor-based systems nas been outlined by 
O'Connell and Richardson [5]. The design goals of that 
operating system were COMM curation independence, 
distributed processing, multiple. protection domains, 
Multiprocessing, and multiprogramming. Because such a 
broad, general operating system is not always required, 
the design provided for a family of operating systems. A 
family member could use a subset of functions for a 
specific application while allowing later extensions. This 
thesis presents the detailed design for such a family 


member. 


Be BASIC CONCEPTS 

DHewarechival Storage System can be the nucleus of a 
E-cume. distributed multiprocessor system. It provides 
“data warehouse facilities for multiple host computers in 
the network. A host may be operating at a single security 
level, or simultaneously at several security levels 
without affecting the Archival Storage System. Information 
storage with multilevel security is provided for Sach host 
connected to a port of the warehouse. Additionally, the 
data warehouse is the mechanism for rroviding controlled 


e among the hosts. Thus, we can apply microprocessor 


e 








technology to address a significant part of the larger 
multilevel security problem [6] for distributed systems. 

A subset of the O'Connell and Richardson design has 
been selected as the basis for the detailed design of the 
Archival Storage System. (The subset chosen omits the 
provisions for multiprocessors, dynamic linkiag, demand 
segmentation, "transient processes, and a user domain.) 
mes upervisor, protocols, and interfaces to the host 
computers are presented in a parallel thesis by Parks [3] 
while detailed design of the Security Kernel is presented 
ais thesis. 

here ar2z “tho components of the Archival Storage 
System Security Kernel which reside in the privileged 
domain of the machine: 1)the distributed kernel and 2) the 
kernel processes. From a logical view, some Kernel 
procedures aeS Stol outed among -allm the Supervisor 
processes in the system, with the remaining procedures 
forming kernel processes. These xernel processes perform 
BEC tons that  arew asynchronous to the supervisor 
processes and are responsible for the shared resources of 
the system (processes, processor, memory, input/output). 

1. Definition of a Process 

A sequential vrocess can be conceptualized as an 
execution point and an address space which is a logical 
KANE than physical entity. All procedures that are in 
the flow (or locus) of control are in the address space. 


ATA DPUN GN operating system, the locus of execution 
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includes those operating system functions which “re 
logically part of the user process. The distributed 
operating system is divided into procedures which are 
Gemmved in normal fashion, but are located in the 
privileged domain. 

2. Multiple Protection Domains 

One requirement for design of a security kernel is 
isolation of the kernel procedures to make them 
tamperproof. A way this can be achieved is to arrange the 
process address space into hardware or software protection 
Ma as: Domains need not be hierarchical, but in this 
case they are. Hierarchical domains are commonly called 
protection rings [7]. 

Sach level in the hierarchy is more privileged 
than the preceding level. In the Archival Storage System 
only two domains are necessary. Other levels must be added 
NI oO the Supervisor if the design is extended to 
include user applications. The distributed Kernel resides 
in the most privileged domain and may access any segment 
within the address space of a process. All systemwide 
databases are in the kernel domain. “Violation of the 
confinement principle described by Lampson [28] and Lipner 
[9] would occur if such information could be passed to 
other domains. 

The Supervisor operates in the outer or least 
privileged protection domain where access to segments and 


external devices is restricted. Only those databases which 





are “process local” may be accessed. This does not prevent 
sharing since different segment numbers and access rights 
for each process can be interpreted and enforced by the 
kernel. Each Supervisor process is required to remain at a 
specified security level within its domain. 

Protection domains may be created by either 
nardware or software. Software implementations of 
protection domains (as in the early Multics [12]) are 
Beastble, but result in a degradation of efficiency. This 
performance loss is unacceptable in many applications. In 
large processors a hardware ring mechanism is sometimes 
used to provide the implementation [7]. This general ring 
mechanism is not available in current microprocessors, but 
two domain machines are available. When supplemented by 
ring-crossing software, this will provide the desired 
multiple domains. 

5. Segmentation 

A segment is defined as a logical grouping of 
information [11], while segmentation is a technique for 
managing segments within an address space. A process's 
address space consists of a collection of procedures and 
data segments. All address specifications require the 
EE ment specification and the offset within the segment 
(l.e., a two-dimensional address). Segments are therefore 
Es ncetiv visible to the user. Unlike pages, sezments are 
aü trarily sized and logical units with Logical 


attritutes to describe them. 











Attributes of segments ame contedmed d a 
aenecture called a segment descriptor. The descriptor 
associates segments with address in memory, size, and 
access allowed. Maintaining all of the descriptors of the 
segments of a process in a descriptor list allows the 
address space of the process to be easily manazed. 

Segmentation offers benefits as a memory 
management scheme. The key advantage is the ability of 
multiple processes to share segments without the 
reauirement of maintaining multiple copies in memory. 
Sener favorable characteristics of segmentation are 
control of memory waste due to fragmentation, creation of 
user virtual memory, dynamic linking of modules, and 
enforcement of controlled segmert access. 

Segmentation eliminates the need to duplicate a 
segment when shared. Having only one copy saves memory and 
eliminates the problem of conflicting data which occurs 
when multiple copies are maintained. Even more central to 
segmentation is the ability of cooveratiag processes to 
communicate with each other through shared segments. 
W er process synchronization and communication are 
necessary functions in a multiprogramming environment. 

4. Information Security 

Most users of computer systems are required to 
sateemardc information from unauthorized access. Examples 
abound: government (classified information), corporations 


(trade secrets), banking (electronic funds transfer), and 





all users of personal data (privacy act). This requirement 
is not relaxed when microprocessors are used instead o? 
(or in support of) large computer systems. Dedicating a 
device to a specific security level (dedicated mode) [6] 
is a method commonly used to meet the security 
requirement. This solution is unsatisfactory for any user 
Ban a requirement to utilize data at more than one access 
class. 

Another solution to the problem of accessing 
mlornation at different security levels is to operate in 
se multilevel mode. In this case both users and 
information at different security classes exist 
Ens taneously on the same computer system. Users are not 
permitted to access information unless authorized by the 
Security policy in effect. 

In the dedicated mode all security measures are 
external to the computer system (2.2., perimeter fencinz, 
guards, door locks, etc.). When a multilevel mode 
environment is used, controls must be internal as well as 
external. Attempts at internal controls have teen tried by 


adding security measures to existing systems with 


rt, 


unsatisfactory results. Numercus cases are documented o 
penetrations (i.e., unauthorized access) of these systems 
[6]. O VU Aso a Name tran Sound design was the 
methodology used in these unsuccessful attempts at 
Security. 


Entenda! oontrols must be designed into a system 


pr 








from its conception. The approach to designing these 
controls is the security kernel methodology. The first 
step using the security kernel methodology is to define 
the security requirements. From this definition a 
conceptual design is created. The conceptual design is 
BHuually a mathematical model which can be rigorously 
proven and provides the basis for testing (certifying) [2] 
all subsequent implementations. 

Three things are reauisite before a system can be 
secure using the security kernel concept: 1) The kernel 
must be isolated cr tamperproof. Obviously i? a penetrator 
can change the kernel software, then the behavior of the 
kernel can be modified. 2) The kernel must be invoked on 
Benny attempt to access information. This requirement can 
be met by initial software interpretation of access on the 
first call to a segment. Thereafter, hardware can enforce 
the access criteria. 3) The kernel must be subject to 
Semtriication. Proof of the mathematical model must be 
followed by thorough testing of the implementation te 
Mesure that each input yields the desired output. Since 
hardware and software are involved, both must be tested 
before the kernel car be certified. 

Ass oremikoaus)y stated, the first step in the design 
DNE hec secere computer system is to define the security 
requirements. A proverly designed computer system is then 


anae With respect. to that definition or policy. à 


scleuritvyevolicy consists 2º the external laws, rules, and 











regulations that establish what access is to be permitted. 
Two dest umet types of Securmey policy exist: 1) 
mom—-discretionary and 2) discretionary. 

Non-discretionary policy involves comparing the 
requested (i.e., the information object’s) access class 
(oac) with the access class of the requestor (i.e., the 
subject) (sac) to insure that they are compatible. For 
example, in the Department of Defense security policy a 
secret cleared individual (subject) may have access to 
documents (objects) which are classified as secret, 
confidential, or unclassified. 

The relationships between different access classes 
can be represented by a lattice structure [12]. This 
Ice structure is totally ordered if all classes are 
related. when the classes are either related or disjoint 
Bae lattice Moecartially ordered. The lattice structure 
interprets the authorized access based on the 
relationships between two labels. The lattice structure 
EkElraction is important because it seems to represent 
EE oractical security policies. By changing the 
enore aton of labels in the non-discretionary security 
module, a different policy can be implenented so that, for 
example, Privacy Act requirements are as enforceable as 
Department of Defense security policies. 

The following interpretation defines the access 
vermitted in a computer system (where € is defined to 


mean unrelated) in terms of subject access class (sac) and 





ject access class (oac): 

sac = oac, read/write permitted 

sac > oac, read permitted (read down) 

sac < oac, write permitted (write up) 

sac % oac, no access 
DOD security policy is represented by a partially ordered 
lattice since security classifications are composed of a 
classification level and a category COMER. secret, 
Beeyotog@taphic or confidential, nuclear). 

Discretionary controls provide a refinement of the 
Bon-discretionary access. A Common example ou 
discretionary controls involves checking an access control 
list before allowing an access. This allows authorized 
subjects (users) to specify who may use that segment 
Main the confines of the non-discretionary policy. The 
DOD  "need-to-know rule is an example of discretionary 
Borıcy. Ir the Archival Storage System non-discretionary 
pucy is enforced by the Supervisor, based on both the 


host and the user. 


IS UCR CR TEE THESIS 
This thesis presents the detailed desizn of a portion 


Ehe Security kernel for an archival file storage 
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facility (distributed kernel procedures and memory manag 


ct 
Sg 


process). Levels of abstraction are used to reduce = 


Alea o? the hierarchical Archival Storage System. 
Bevel 2. contains the Supervisor and operates in tae 
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Virtual environment created by tne Kernel. The Supervisor 


ay 





does not control the hardware of the system but applies 
Ener hardware resources only by appealing to the functions 
Ehe Kernel. Calls to procedures at different levels may 
only be made in a downward direction and corresponding 
returns only in an upward direction (i.e., the Kernel may 
not call upon the Supervisor tc accomplish any task). This 
restriction, rigidly enforced at all levels of abstraction 
in the design, reduces the number and type of interactions 
NENE system. 

Figure 1 shows the process structure of the system 
Baa Che distributed and non-distributed kernel. The 
asynchronous Memory Manager and I/O Manager are kernel 
mmoeesses. The remaining kernel procedures are distributed 
in all the supervisor processes. 

In the next chapter the details of the design are 
Enesented. Although this is not an implementation, the 
Zilog 28081 Microprocessor [13! with the Z&@13 MMU Memory 
Management Unit is used as the hardware base for this 
research. Choices made during the design process wers 
often influenced by the hardware features available. The 
28920 family of devices is not mandatory for implementing 
the archival Storage System. Cther microprocessors exist 
En are capable of supporting a secure system. 


Algorithms and data structures are presented ir the 


f» 


high level language PINAS (ile PL/I’ is 
Pascal-like, block-structured language. Designed by Zilocg, 


the language can be compiled to Z8000 instruction coce. 


PAN 
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Kernel 
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Figure 1. Process View 
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PLZ/ASM [15] is used where machine level instructions for 
direct hardware manipulation are required. These two 
languages for the 28900 are used because of the capability 
of linking modules of either language to the other. 


Additionally, PLZ/ASM has the same high level data 


(D 


structures and structured control mechanisms present in 
mec/sis. 

ie conclusions reached during this research are 
presented in the last chapter. Topics for further research 
and implementatior are identified, including those in the 
area of secure systems. With this multilevel data-store, a 
secure distributed microprecessor system can be 
implemented using communications lines to interface 


distributed processors of the network to the data 


warehouse." 
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IT.  DEMAILEDADESE GN 


A. HARDWARE REQUIREMENTS 
Theoretically any processor hardware is usable for 
secure computer systems. However, in practice certain 
hardware features are essential for efficiency. In 
Edition, complexity of the software portion of the 
security kernel is highly dependent upon the capebilities 
of the hardware. Because simplification o? the kernel 
results in an easier proof of correctness, rt is 
worthwhile to use additional hardware to achieve security. 
One essential hardware feature is a segmentation 
mechanism. Segmentation allows the use of one uniform type 
DE information object, the segment. Kernel software which 
deals with logical objects is then simplified. Paging 
hardware without segmentation does not rrovide a correct 
structure for objects, since pages are physical objects 
Ben physical attributes. For example, an access right is 
o eical attribute. Applying an access right to a 
Peysical object ‘as is the case for IBM 379 protection 
"locks s [11]) obscures the purpose of the attribute, is 
out of context, and adds complexity to the supporting 
mechanism. 
A segment address consists of a segment name and an 
ffset within the segment. This logical address must be 
transformed into an absolute address before it can be 
used. While software is capable of making tais 


transformation, hardware can perform the mapping more 
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efficiently and simultaneously check access while doing 
the mapping. 

Multiple execution domains are also considered 
essential in hardware. This feature is used in current 
emputer systems to protect the operating system from 
applications programs, but until recently this feature has 
not been available in microprocessor hardware. In the 
initial Archival Storage System implementation only two 
domains are necessary since applications programs do not 
exist inside the boundaries of the system. Protecting the 
Kernel from the Supervisor is the only domain protection 
required. If user utilities are added to the design, traen 
another domain will be necessary to protect the Supervisor 
from user tampering. 

With the introduction of Zilog’s Z8000, the above 
hardware features are available in the microprocessor 
category. The desien of the Archival Storage System is 
targeted toward a hardware system based upon the 25001 
segmented microprocessor [16] ani the 288108 MMU Memory 
Management Unit [17]. The ZE901 is a 16-bit two-domain 
microprocessor which produces a 23-bit segmented address. 
The 28910 MMU maps the 23-bit logical address into a 
24-bit absolute address and allows the capability of 
addressing up to 128 segments of 64K bytes each in the 
two-dimensional memory space. 


In addition to the address mapping hardware, the MMU 


also provides memory access protection. Segment access may 








be set to write (read implied), read, or execute only. 
When an unauthorized access is attempted, the MMU prevents 
the access, then sends a trap (or fault) signal to the 
IO Processor. A trap is an internal interrupt which is 
synchronous rather than asynchronous to the cycling of the 
processor and must be resolved by the processor before 
processing can continue. 

The mWLCProprocessor AO Supports LO Proce cero 
domains. The MMU provides the implementation of two 
hardware -rings by checking for system or user status on 
each access to a segment. The bit in the MMU which 
specifies system or normal mode, thus specifies which 
segments are accessible in just the Kernel ring and which 
segments are also accessible in the Supervisor rinz. Thus 
a process must cross into the Kernel ring to access the 
Kernel vrimitives. If more than two rings are recuired, an 
additional MMU (up to eight total) may be employed per 
ring. 

The hardware also supports resource CON TIO by 
miting the use of certain machine instructions. In the 
system mode all machine instructions can be executed. when 
in user mode, the hardware will not allow the use of 
Ia put Out out BASErUC TONS, certain machine COntrol 
instructions, or special input/output instructions (used 
CO cad and control the MMU). Thus the Kernel can control 
the microprocessor, the main memory (through the MMU), and 


all external devices. 
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Hardware features other than those described above are 
indicated from a performance standpoint. For instance, a 
direct memory access (DMA) device could make memory to 
memory, memory to port, or port to memory transfers faster 
Huan similar transfers under direct CPU control. This 
would aliow the CPU to continue with other tasks while the 
DMA is processing the data transfers. Protection cf memory 
Bam Still be realized by routing the DMA through the MMU. 
The DMA would have to be “smart” enough to handle an 
access violation trap or the Kernel would have to 
guarantee, ty MMU set-up, that the DMA would not violate 
the security policy. This type of hardware is not crucial 
Ro the desien at this level, and the decision on its use 
is left to the implementor. 

The MMU doss lack a descriptor base register 
capability [12]. Process switches without this facility 
require at least selective unloading and loading o? the 
descriptor registers in the MMU, and a process switch 
Would take roughly two (2) milliseconds to accomplish in 
teas manner. It is evident that process switching may lead 
Le gthrasring problems if done too often. There are ways 
the implementor might avoid this problem (e.g., dedicating 
Bi MUMU to each process, then switching MMUS rather then 


lcading/unloading a single MMU). 


B. PROPOSED KERNEL DESIGN 
1. Notation 


NOtatwones tS important in maxing algorithms 
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understandable. It should not, however, require more 
thought to understand the notation than the central 
concept. Since this thesis presents a detailed design, a 
notation as close as possible to an actual language which 
can compile to Z8000 machine code was desired. PLZ 
languages are used as a notation to illustrate the data 
structures and procedures. However, the code as Shown ir 
the figures cannot be directly implemented. Among other 
changes, procedure order has been rearranged to make 
explanation of the modules more logical. This change would 
violate a PLZ/SYS implementation rule that procedures must 
be declared before they can be invoked. 

The details of the actual Rise, Si language 
implementation may be different from that assumed in this 
sis. In particular, the specific method of parameter 
passing between PLZ/ASM and PLZ/SYS is unknown at this 
time. The implementor should carefully investigate now 
passing of parameters in the actual language 
implementaticn effects the interfaces between modules. 

Because of the terminology used in the 258900 
mMleroprocessor specifications tne Supervisor may be 
meeerre’c to as operating in the normal or user mode. If 
Ee term system mode is used, it refers to the <ernel 
oman of execution. 


2. Kernel Overview 
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The distributed Xernel modules exist on 
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levels (figure 2). Tach module creates a different 
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of abstraction [18]. At level 1 or the innermost level is 
Ee Inner Traffic Controller. Its primary task is the 
Eon irol of virtual processors and the multiplexing of 
virtual processors onto the real processor. The 
Inner Traffic Controller uses the Virtual Processor Table 
Soma management tool for this multiplexinz of virtual 
processors. 

At level 2 is DE Isac Cort ro er The 
Metric Controller creates the sequential process 
abstraction [17]. A process can be in one of two states: 
1) blocked or 2) unblocked. When blocxed, it must wait for 
the occurrence of some event. Since the process cannot 
proceed until that event occurs, the virtual processor is 
“reed and then allocated to another Process. When 
untlocked a process is either ready or running. In the 
ready state, the process can run when a virtual processor 
END --i2ned to ii. The ready state can be entered from 
either the running or blocked state (figure 3). 

The Won Discretionary Security Module is also on 
level 2. This module 1s charged with interpretation of the 
SeGunity policy in effect. It compares the two labels 
which are passed to it and determines the relationship of 
the labels based on a lattice structure known to tne 
module. This relationship is then used by the kernel to 
determine authorized access to objects (segments OT 
parts). It is emphasized that the Kernel makes decisions 


Eka access based on relationships (=, <, >, not related) 
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and not on the labels themselves. Dye 
pomgDIscretionary Security Module is the only nodule in 
the Kernel which makes any interpretation of security 
labels. This allows mos? of the «practical security 
policies to be implemented simply by changing the 
Non Discretionary Security Module. 

At level 5 is the Segment Manager. Using the MMU 
mapping to real memory brovided by the hardware, the 
Segment Manager creates a segmented virtual memory for the 
BMOCESS. Because of the limitations of the hardware (lack 
of a paging mechanism), segments are not dynamically 
allocated real memory. The size of a requested segment is 
fixed (or determined) at the time it is created ard may 
not change. The Supervisor has several options in order to 
handle the problem of growing segment size: 1) Allocate 
the maximum size to every segment which is wasteful of 
memory, 2) copy the segment intc a larger segment whenever 
the size changes which is wasteful of processor cycles, 3) 
create a  super-segment as a collection of segments, or 
4) some combination of the above. By requirinz the 
Supervisor to handle this problem, the initial Xernel 
implementation is simpler. 

The whole segment must be swapved into maia memory 
in order to be used. The MMU supports segments ranging in 
EE rom 256 bytes to 64K bytes im multiples of 256 
bytes. Additionally, the hardware forces another 


constr int ron the desien. Without paging, Wo allocation 
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schemes are available to the designer: 1) a demand 
segmentation memory management scheme (load the segment in 
response to a fault) or 2) a partitioned allocation 
Scheme. In this design a partitioned allocation scheme is 
used to make the Kernel less complex. ?art of the burden 
of memory management is then forced on the Supervisor. The 
supervisor of each process is given a fixed amount of 
linear virtual core. Linear ‘virtual core” is 
distinguished from the two-dimensional virtual memory 
created by the segmentation. The Supervisor, by requests 
to the Kerrel, may fill virtual core with Segments as it 
chooses. The Supervisor of each process must manage its 
own virtual core and fit any segments it uses within the 
Emumndaries of Dnus Viral core. The partitioned 
allocation portion of the memory management scheme is 
Emgported by the Memory Manager process of the 
non-distributed Kernel. 

Goe non distributed portion of the Kernel resides 
iwa two kernel processes: 1) Memory Manager and 2) 
BiManager. These two processes are responsible for 
EC ions which are not legically part of the supervisor 
processes because they can function asynchronously to the 
processes. The Memory Manager moves segments within the 
Mn cal memory space of the system. These transfers mey 
be main memory to main memory, main memory to secondary 
Storage, or seccndary storage to main memory. Main memory 


to main memory moves are made tecause of a cesign decision 





to restrict sharing of the same copy of a segment unless 
at least one of the sharing processes has write permission 
to the segment. Whenever two processes share a segment and 
neither has write access, two copies of the segment will 
Eugst-—-one in each virtual processor local memory. This 
trade-off results in less complexity in the kernel and 
when the design is expanded to a multiprocessor 
implementation, bus contention is minimized [5]. The 
problems associated with the existence of multiple covies 
in memory are not present since the segment is not 
writeable. 

Whenever a segment is to be shared and is 
writeable, then the segment must be moved to the real 
processor global memory. Movement of the sezment is easily 
accomplished by updating the appropriate MMUs to reflect 
meewnew location of the segment. This concept of a process 
local and global memory is analogous to processor local 
nd lobal memorias in multiprocessor systems. [Ia those 
systems, each real processor owns a local memory, while 
the system centrols the global memory used by all 
processors for shared information. 

The 1/0 Manager is responsible for routing 
segments across the system boundary, viz., moving data 
between exterral ports of the system and main memory. “The 
I/O Mamazer does not try to interpret the data, tut simply 
ERE es a transfer service. All the ports have specific 


See classitications and de hard-wired. Miis allows 
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Dies [/O0 Manager to function without requiring labels or 
other security mechanisms to determine access class. 
Having all Hosts at a fixed security level is a design 
choice for the Archival Storage System. Hosts can be at 
multiple levels if the design is modified to accept 
"trusted labels. In the present design the Host computer 
m required to te at the level of the port and to handle 
data consistent with the security policy in effect. 

Since the hardware does not completely support the 
ring structure, software (Gate Keeper) is needed for the 
ring-crossing mechanism and thus isolation of the Kernel. 
All calls to the distributed Kernel and interprocess 
Communication with the non-distributed Kernel from the 
Perisor must pass through the Gate Keeper. The function 
Berne Gate Keeper is to provide the Sole entry Point or 
gate DC GAS erel ring, validate the call dad 
M nents, and transfer the call to the appropriate kernel 
mate: If a call is made incorrectly the Gate Keeper sets 
a return message to an error code, and returns without 
"her action. The Gate Keeper is the ring-crossing 


me nalism of the Archival Storage System. 


o. Gate Keeper Module 


The Gate Keeper Module (shown in Appendix A rather 
than as a figure because of its length) consists of 
procedures and primary data structures and is the sole 
entry point into the Kernel from the Supervisor. The 


Gate Keeper Module is written in PLZ/ASM since it isa 
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trap handler. (The user registers must be saved when the 
handler is invoked which requires access to the hardware.) 
When the Supervisor wishes to invoke the Kernel it must 
put the argument list and space for any return message in 
a segment with read/write access in the Supervisor ring. 
When the system call is made, the pointer to the arguments 
is required to be in a double register. The system call 
BrouructloOn is thensexecuted, with trae function-code for 
the requested Kernel procedure as a parameter within the 
instruction. This causes the machine to save the program 
counter, flags and control word. and the #Werction 
itself on the system (kernel) stack. An unconditional jump 
(hardware initiated) is then made to the Program Status 
Area (a vector table) (figure 4) where the machine state 
On the system call instruction is fetched. The Program 
Status Area is established at system generation and 
consists of “frames” which contain the machire state and 
location of the interrupt and trap handlers. The processor 
then begins execution in tre Kernel ring. 

The Gate Keeper first saves the user processor 
registers and retrieves tne pointer to tne argument list. 
If the argument list is located in a read/write segment of 
the calling (Supervisor) ring, a copy of the argument list 
is put onto the system stack. However, if tne area 
indicated by the calling ring is aot in the read/write 
address space of the process, the Gate Keeper will nor 


return an error code. (There is no place to return it!) 
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The Gate Keeper restores the user environment and makes a 
normal return. 

The Gate Keeper uses a table (figure 5) to check 
the range of the function code. If the Gate deeper now 
discovers an error during the validation process, it sets 
the return message to an error code, copies the argument 
list back to the user area, and returns in the usual way. 
tae call is valid, the Gate Keeper calis the 
appropriate module [Goss Segment Manager) at the 
requested entry point into the module. 

When the module has completed the reauested task 
NEUGUNPRS tO the Gate Keeper. The return message is then 
copied to the user s return argument, and a return to the 
Mere ning occurs. All entries into and exits from the 
Kernel are through the Gate Keeper. 

Parameter passing to and from the Kernel is by 


anne oniy: Sinca implementation details of kow PILZ 


modules pass parameters are unknown, the decision on the 
Peecise mechanism for argument passing is left for the 


Emplementor. It may be best to align the method of 
parameter passing as closely as possible to the method 
used by the PLZ/STS language. 
4. Segment Manager Module 
The Segment Manager is responsible for managing 
the segmented physical memory and uses the 
Known Segment Table (XST) as its primary database. In 


keeping with the loop-free structure and since tbe 
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seement Manager is the only module at level 3 of the 
Berner, only calls external to the Kernel domain may be 
made to the Segment Manager. There are six entries into 
the Segment Manager in this implementation: 

1) Create Segment 

2) Delete Segment 

3) Make Known 

4) Terminate 

Seo wae In 

6) Swap Out 

a. Known Segment Table 

The data structure used by the Segment Manager 
to manage segments is the Known Segment Table (ZST). The 
KST is a process local” data structure and contains ar 
satry for each segment which the process has declared an 
intention to use (viz., made-krown ). The segments may or 
May not be located in main memory. If a segment has an 
entry in the KST, then the segment is described as xnowr 
to the vrocess. In this design it will also nave aa entry 
in the Active Segment Table (4ST--a Memory Manager 
database exolained later) and can te described as active. 
The KST (figure 6) is indexed by the segment numbers 
(Segment #) which are assigned by the Segment Manager. The 
BPeementer also corresponds to the MMU descriptor register 
Mom Eine segment. The ASTE # is the setive Segment Tabie 
entry number and is obtained from the Memory Manager. The 


ASTE # is the handle which is passed to the 
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Memory Manager when necessary to identify a particular 
Betive segment. The Size field is an integer which is the 
size of the segment in bytes divided by 256. All segments 
are created in multiples of 256 bytes because o? MMU 
constraints. An upper bound (Max Segment Size) is placed 
on the segment Size by the design (explained later). å 
flag known as In Core is used to indicate whether the 
segment is in main memory or on secondary storage. 

The last field in the XST entry is tae access 
Bino? the segment. This is a label which indicates tne 
Early classification of the segment. Interpretation o? 
the Class to determine an access mode (read or reac/write) 
is performed oy the software (Oy a call to 
Reis cretlonary Security) on first reference; thereatter 
the access mode is enforced by the MMU. 

Mao shows both the logical view andere 
Peeevariavle declaration for the EST. (Max KST Size às 
hardware dependent and is equal to the maximum number of 
ZGements which can be mapped by the MMU. To access ar 
element of the database the following notation is used: 

KST [Segment #]. ASTE zs 
If Segment # is equal to 195 then the above statement will 
Bererence the ASTE # field of the KST eniry fcr segment 
number 195. 
b. Creation and Deletion of Segmests 


Create Segment and Delete Segment are two of 


the six Supervisor entries into the Segment manager. 
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Known Segment Table Lozical View 


Type 
KST Entry Record [ASTE 4 AST Index 
size Integer 
Access Mode Integer 
In Core Byte 
Class Loneword] 


Internal araro the egzmerigkanazer =! 
TATA? [Max KST Size KST Entry] 


Known Segment Table Database Definition 


Figure 6. Known Segment Table 





Create Segment (fizure 7) is the function which adds a new 
segment to the Archival Storage System after validating 
the parameters which are passed. The creation of a segment 
is accomplished by requesting the Memory Manager process 
to make an entry in the Alias Table and to allocate 
storage on secondary media. 

The Alias Table is a database which is 
maintained by the Memory Manager. It isa result of the 
llasing scheme used by the HXernel to prevent passing 
systemwide information (such as the unique identification 
of a segment) out of the Kernel [28]. The alias of a 
segment is the segment number of a “mentor. segment (a 
process local variable) and the entry number in the 
Alias Table. The princival implication of tne aliasing 
scheme is that a mentor segment must ve xnowr before a 
segment Can be created. Tne Alias Table will be further 
explained in a succeedine section. 

The arguments which must be passed to 
Bake Segment are the Mentor Segment *, the desired 


Entry # (in the Alias Table), the Class of the segment (a 


| 


label), and the desired Size of the segment. he XST is 


searched to insure that the Mentor segment is znown. Next, 


(D 


ücuDiscretionary Security must be called to determine if 
the segnent is comvatible [2]. (To be compatible, a mentor 
Emei classification must be less than or equa. to me 
created segment.) The compatibility caec« caa be performed 


in the Segment Manager or the Memory_Manager. In addition 
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Create Segment Procedure (Mentor Segment 4 Integer 
Entry * Integer 
Class Longword 
Size Integer) 
Returns (Success Code Integer) 


Entry 
Do 
If KST[Mentor Segment #].ASTE # = Null 
Then Success Code := Mentor Seg Not Found 
Exit 
Fi 
1£f Non Disc Security(Process Class, 
KST[Mentor_Segment_#).Class) <> Equal 
Then Success Code := Not_Allowed 
Exit 


Compat Check := Non Disc Security(Class, 
KST(Mentor Segment #].Class) 

If Compat Check = Less Than 
Orif Compat Check = Not Related 
Then Success Code := Not Compatible 

Exit 
Fi 
WE Size 9 Max Segment Size 
Then Success Code :- Segment Too Large 

Exit 
Fi 
Signal (Memory Manager ,Create Entry, 

KST (Mentor Segment #].ASTE #,Entry #,Class,Size) 
puecess Code := walt 
Od 


Mmd Create Segment 


Figure 7. Create_Segment Procedure 
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Ro Lhe Compatibility check, a check must be made to 
determine if the process access class is equal to the 
mecess Class of the Alias Table since adding an entry 
pies write permission to the 'Alias Table. A check is 
Poem Made on the Size parameter to insure that it is in 
the range of 256 bytes to 32K bytes. The maximun size o? a 
segment is determined by the size of the design of the 
secondary storage vaze table and the hardware constrains 
the segment to multiples of 256. 

[It an error is discovered during any of the 
preceding checks, then an appropriate error code is 
memurned (@€.e@., Parent Segment Not Found). If tnere are no 
errors, the Segment Manager Signals the Memory Manager 
Ea request to make an entry in the Alias Table. The 
segment Manager must Wait for a success code from tne 
Nemo y Manageresirce the Entry # can only be checked for a 
duplication by the Memory Manager. When the Memory Manager 
Signals the Segment Manager that the task has peen 
completed, the Segment Manager returns the Success Code to 
the process. Note that the segment has only been created 
and if the Supervisor now wishes to reference the segment 
it must first request the segment be entered into the KST 
(Make Known). 

Delete Segment (figure €) accomplishes che 
reverse of Create Segment, that is the removal of a 
directory entry. The two impur parameters BOT 


PN 


Delete Segment are Mentor Sezment * end zatry 3. "Neam, 





Delete Segment Procedure (Mentor Segment # Integer 
Entry & Integer) 
Returns (Success Code Integer) 


Entry 
Do 
If KST(Mentor Segment #J.ASTE 4 = Null 
Then Success Code := Mentor Seg Not Found 
Exit 
Fi 
If Non Disc Security(Process Class, 
KST[Mentor Segment #].Class) = Equal 
Then Signal (Memory Manager, Delete Entry, 
KST [Mentor Segment #].ASTE #,Entry #) 
success Code := Wait 
Else Success Code := Not_Allowed 
Ei 
Od 


End Delete_Segment 


Figure 8. Delete_Segent Procedure 


46 





the mentor segment must be ENOWN before the 
segment Manager can honor the request. Since the mentor 
segment must be known, compatibility was checked when the 
segment was created. The process access class must also te 
equal to the access class of the mentor segment since 
deleting an entry implies write permission. when all 


Security checks have been made, the Segment Manager 


(D 


Signals the Memory Manager to delete the entry from th 
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Eas Table. BINE segment Manager Waits for 
Hum Manager to complete the task and it returns the 
Emccessesode from the Memory Manager to the Supervisor 
process. The Wait is necessary because an error occurs if 
Pee entor Segment às not empty prior to the deletion. 
c. Managing the Segmented Address Space 

PAG NCE 55 MUsL declare an intentlom ko use a 
segment before it can reference the segment. This 
declaration introduces the segment into the address space 
Berne process. The way the Supervisor declares its 
Mention to use a segment is to ask that a Segnen: # be 
assigned. This results in an entry in the 
Known Segment Table. Make Énown is the entry point into 
the Segment Manager tc accomplish an entry ic the KST. 

A cal] to Make Xnowr (figure 3) requires three 
parameters: 1) Mentor Segment #, 2) Entry 2, and 53) 
Access Mode Desired. Segrert # is the value whick the 
Segment Manager returns to the Supervisor process and is 


the index to the KST entry end to the segment descriptor 
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Make Known Procedure (Mentor Segment # Integer 
Entry * Integer 
Access Mode Desired Access Mode) 


Returns (Segment &4 Integer 
Access Mode ¿Allowed Access Mode 
Success Code Integer) 


Local Index Integer 
ASTE # Word 
Class Longword 
Size Integer 


Entry 
Get Seg #: Do 
If KST (Mentor Segment_#] .ASTE# = Null 
Then Success Code := Mentor _Not_Xnown 
Exit From Get Seg # 
Else Signal (Memory Manager,Activate, 
XST (Mentor Segment #].ASTE #,Entry #) 
ASTS 4$, Class, Size, Success Code :- Wait 
If Success Code - Segment Found 
Then Index := Y 
search: Do 
RES dez] GASTE # = AST 4 
Then Segment # :- Index 
Success Code := Already Known 
Access Mode Allowed := 
KST[Segment_*].4ccess Mode 
exit ETOM Gek Ses AH 
Fi 
Index *- 1 
If Index > Max Number Of Segments 
Then Exit From Search 
Fi 
Repeat From Search 
Od !Search! 


Figure 9. Make_Known Procedure 
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Index Fed 
Find Entry: Do 
If KST [Index] .ASTE # = Null 
Then If Non Disc Security(Process Class, 
Class) = Less Tyan 
Orif Non_Disc_Security(Process Class, 
Class) = Not Related 
Then Access Mode Allowed := Null 
Else If Non Disc Security(Process Class, 
Class) = Equal 
Then Access Mode Allowed := 
Access Mode Desired 
Else Access Mode Allowed := Read 
Fi 
Fi 
If Access Mode Allowed <> Null 
Then Segment # :- Index 
Dem. #] .ASTE 9 :- ASTZ 4 
XST[Segment_*].Class := Class 
EST(Segment 4].Access Mode := 
_ Access Mode_ Allowed 
KST(Segment_#].Size := Size 
EST(Segment 4].In Core := No 
Success Code :- Segment Found 
Inner TC(Add Seg,Segment 4, 
Access Mode Allowed) 
Else Segment # :- Null 
Success Code :- Not Allowed 
E 
Exit From Find Entry 
Fi 
Index += 1 
If Index > Max_Number_Of_Segments 
Then Segment # := No Segments Avail 
Exit From Get see 5 
Fi 
Repeat From Fird Entry 
Od [Find Entry! 
Od IGet Seg #! 


End Maxe Known 


Figure 9. Make Known Procedure (Continued) 
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in the MMU hardware, Different processes using the same 
segment will not have the same Segment # for the segmert, 
since each process has its own KST. Three parameters are 
returned from Make Known: 1) the assigned Segment 5, 2) 
the Access Mode Allowed which may be less than 
Mess Mode Requested, and 3) a Success Code. If the 
puccess Code indicates an error the first two parameters 
are Null. 

Make Known first Sigrals the Memory Manager 
and Waits for the ASTE # of the segment. If more than two 
rings were implemented, ring brackets would also be 
required from the Memory Manager [19]. A search of the KST 
then will reveal if the segment is already known. I? it is 
known, the assigned Segment # the Access Mode Allowed 
(unchanged), and a Success Code of Already Xnown are 
returned. Access Mode Allowed cannot te Changed LOT 
segments in the address space. If there is no entry in the 
Moet, an entry is made by filling in the columzrs of the XST 
at the toS available Segment_*. 
ENPUScrettonary security is called to interpret the 
Ea lanes 0? the subject and the object. fccess to 
the segnent is then granted with the access allowed equal 
to BE Less privileged of Access Mode _ Desired or 
aaccess alimowable. If write access is requested but 
security allows only read, read is the access granted. A 
call must also be made to the Inner Traffic_Controller to 


add the segment descriptor to the hardware descriptor list 


Cn 
G 





(MMU) and the software image of the descripter list. 

If the maximum number of segments is exceeded 
Make Known will return No Segment Available. The process 
then has the option of terminating any other segment to 
make room for the required segment. (Note tnat the maximum 
number of segments allowed by the hardware could de 
exceeded without using all of the linear "virtual core" 
allocation or conversely.) Terminate is the entry point in 
the Segmert Manager to remove a segment from the XST. 

Terminate (figure 10) is responsible for 
removing the segment frcm the address space and reflects 
this by removing the entry from the KST. The only argument 
which must be passed is the Segment 2 to be terminated. 
he return argument is a „Success Code. There are four 
errors which can be found by the Segment Manager: 1) a 
segment which is not known, 2) attempting to termiaate a 
segment still loaded in the process virtual core, 3) 
attempting to terminate a Kernel segment, and 4) passinz 


an invalid Segment # (too large). The Memory Manager is 


Ui 
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Signaled to Deactivate the segment (remove the AST entry) 
and a Wait occurs until the Deactivate is completed. Note 
that the Wait is to insure that a race conditior between 
the Memory Manager and Supervisor process [11] does not 


occur. The KST entry is deleted by setting the AST = of 
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anja Controller to delete the segment from 


descriptor segment and returning. 





Terminate Procedure (Segment # Integer) 
Returns (Success Code Integer) 


Entry 
Do 
If KST(Segment_#] .ASTE_# = Null 
Then Success Code := Segment_Not Known 
Exit 


Fi 

MS [Seement Al .In Core = Yes 

Then Success Code := Segment [In Core 
Exit 

Fi 

If Segment # <= Number Kernel Segments 

Then Success Code := Kernel Segment 
Exit 

Fi 

If Segment * » Mar Segment + 

Then Success Code := Invalid Segment # 
Exit 

D 

Signal(Memory Manager,Deactivate,KST[Segment #].ASTZ #) 

BINCOHSSOOdSG > Walt 

KST(Segment 4) .ASTE & :- Null 

Inner TC(Delete Seg ,Segment_#) 

Od 


End Terminate 


Figure 19. Terminate Procedure 
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d. Moving Segments into Memory 

Swap In (figure 11) and Swap Cut (figure 12) 
mee the two procedures in the Segment Manager which move 
segments between main memory and secondary Storage. 
(Secondary storage is used as a generic term in this 
thesis to indicate all memory of a computer system other 
than main or core memory. It includes tertiary’ or lower 
order memory.) To move a segment from secondary storage to 
Dux memory, a process must call Swap In witn toe 
Segment # and Base Address as arguments. Base Address is 
Ene location in the linear virtual core of the process 
where the segment is to begin. This is a virtual core 
address and does not correspond to a real address in 
memory; in fact, memory cannot be addressed at all except 
myeadaaressing a segment. The Segment Manager indexes to 
the segment in the KST to retrieve the necessary 
attributes for moving the segment. If the segment is not 
mana, segment Not Found 1s returned. Arter obtaining the 
attributes of the segment, the Segment Manager Signals the 
Memory Manager to do the transfer. await is then executed 
until the Memory_Manager can send the Absolute_Address in 
real memory to the Segment Manager. This information is 
Bassed to the Inner Traffic Controller to update tre 
absolute address in the hardware and software descriptor 
lists. This procedure only works because of the design 
ENG no: to unload a process from a virtuai processor. 


If processes are unloaded the Memcry_Manager would nave to 





Swap In Procedure (Segment # Integer 
Base Address Word) 
Returns (Success Code Integer) 


Entry 
If XST[Segment_#]) ..ASTE_# = Null 
Then Success_Code := Seg_Not_Found 
Exit 
Fi 
Signal (Memory Manager,In,Segment #, 
KST (Segment np ASTE 4,Base "Address, 
KST[Segment #]>Access Mode)” 
Absolute_Address,Success_Code := Wait 
If Success_Code = Swapped_In 
Then loner TC (Load,Segment #,Absolute Address, 
KST[Segment. zu Size) 
KST(Segment_#].In Core := Yes 
Fi 
End Swap In 


pure 11. Swap In Procedure 
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Swap Out Procedure (Segment # Integer) 
Returns (Success Code Integer) 


Entry 
If XST[Segment_#].ASTE_# = Null 
Then Success Code := Seg Not Tound 
Exit 
EN 
Written := Inner_TC (Unload,Segment_#) 
Signal (Memory Manager,d0ut,XST [Segment #].ASTE #,Written) 
'KST[(Segment #].In Core :- No 
success Code :- Swapped Out 


End Swap Out 


Mare T2. Swap Qu P PPOCedue 


cn 
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Ex the Inner Traffic Controllers The parameter returpéd 
to the process indicates if the segment swap-in was 
Emuceessful. 

The move in the other direction--main memory 
E secondary storagé--is performed by Swap Out. The only 
input argument is the Segment 4 aud Success Code is the 
comly return argument. After validation of the Segment *, 
the Segment Manager calls the Inner Traffic Controller to 
obtain the status of the hardware changed bit. This is ir 
turn passed by Signal to the Memory Manager to mate the 
change. success Code is set to Swap Out ari the 
Segment Manager returns. If more than one processor is 
used in the system, race conditions should be investigated 
in this procedure of allowing the Segment Manager rather 
than De Memory Manager to call the 
mivepetraffic Controller. 

TOs UCL Mit ne usual Order For invorina tie 
element Manager functions has not been specified. There is 
a usual sequence of events. In order: Create Segment to 
make an Alias Table entry, Make ínown to introduce tne 
segment into the address space, and Swap In to move the 
segment into the process's virtual core are the steps 
necessary before a process can make a reference to a 
segment. Conversely, Swap Out, Terminate, and 
Delete Segment is the order to move a segment from main 
memory to secondary storage, remove the entry from the KSI 


mudescriptor Sron the MMU, and remove the segment from 





mee address space. If the functions are called in any 
Other order, the usual result is an error condition and no 
action is taken. No harm results from calls made out of 
sequence. 
Em irartiíic Controller Module 
ne Traffic_Controller is responsible fom 
Bu plexlng processes onto virtual processors. A virtual 
processor is an abstraction which describes a logical 
puocessor. There are multiple virtual processors which 
exist on a single physical processor. The 
Traffic Controller is also the Kernel module waich 
pois the interprocess communication primitíves, Block 
and Wake Up. In the Archival Storage System, 5locx and 
Wake Up are tne er. of tbe siz user entries into the 
Kernel. There are four other procedures in the 
imarfic Controller which implement Ene Screlulime 
algorithm and vrovide message queue services for Block and 
Wake Up. 
a. Active Process Table 
The database of the Traffic Controller is the 
Active Process Table (APT) (figure 13). This is a 
fixed-size table in the Kernel because of the decision not 
Lo create or destroy processes. When the Archival Storage 
System goes through system generation, each process will 
be created and an entry made in the APT. The process will 
wen be active for the life of the system. Each active 


process will have a uniaue identifier (Process ID) which 








BHuocess ID 
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Figure 13. Active Process Table 
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is also the index to the APT. Note that if processes were 
created and destroyed, then allowing Process IDs to leave 
Be Kernel could create a communication path. In that case 
the Process ID should be virtualized. The State field of 
the APT indicates whether a process is blocked, ready, or 
running. 

An explanation of the interprocess 
communication primitives is necessary here. Block and 
Wake Up [19] are the interprocess communication primitives 
used by cooperating processes in the Supervisor domain. 
Invocation of the primitives is actually a call to the 
ieee Controller ard causes the Traffic Controller to 
execute the scheduling algorithm. A process calls Wake Jp 
when it has a message or task for another process. Waxe Up 
will set the state of a blocked process to ready. If the 
mmeeess is ready or running it will have no effect om the 
status of the process. When a process cannot continue 
Eon Until a reply to a Wake Up is received, the 
Process mist block itself. Block will set tne proccess 


status to blocked. 


(D 


Within the Kernel Signal and Wait are th 


Ly 
(D 


Primitives used for communication. They function in i 
same manner as Block and Waxe up, but ere calls to the 
mner Traffic Controller instead of UE 
ee Controller Signal and Wait are bounded ia time 
which indicates that they are guaranteed to return. Block 


nd fake Up are mot bounded since no claims can te mace 
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Mout correctness of calls from outside the Kernel. It is 
possible for a user process to call Block erroneously and 
never be heard from again. 

The Wake-Up Waiting Switch is Saltzer’s [19] 
mechanism Lor synchronization of interprocess 
Eoumunication primitives. Without the switch a race 
condition can occur. For example, the following sequence 
of events could happen because processes can pus 
simultaneously: 

1) Process A looks in its work queue 

and finds it empty. 

2) Process B puts a task in A's work queue. 

3) B wakes up A. 

4) A blocks itself. 

At step 3, A was running, so the wake-up sent by 3 was 
ignored. When A called block, a task is in the work queue, 
but A missed the wake-up signal, so the task remains 
Eucompleted., In particular, if A was expecting some event 
aLe for Ato continue, A may never wake-up. 

The Make-Up “Waiting switch orevents tne 
occurrence of such a situation by requiring the following 
sequence of actions: 

Pmocess Bi 

1) Process 3 puts task in Process A’s 
work queue. 
2) Waxe-up A and turn wake-up waiting 


Switch on. 


6¢ 








Enoces5 A: 
1) Reset the wake-up waiting switch to off. 
2) Look in the work queue and find it empty. 
3) Call Block, which returns if wake-up 
Waiting switch is on. 
Now, the above sequences can OCT in any time 
relationship and the wake-un signal will have the desired 
effect. 

MTree Controller eseas the priority field 
for determining what process to schedule to run on the 
RAMAN processor. The Required Virtual Processor field is 
Used to bind a loaded process to a specific virtual 
processor. Only two processes run on a Va 
processor--the loaded process and the Idle process. This 
is a direct result of the simplifying design choice (to 
have all processes loaded) made for the Archival Storage 
System. In general, vrocesses must be loaded and unloaded. 
Ue Tdle process is put into the running state whenever 
the loaded process blocks itself. 

o. Loterprocess Communication Primitives 

Because the Archival Storage System does rot 
Elow creation or destruction of processes except at 
ENE em zeneration, the only external entry points into the 
Eric Gortroller are Block and “Wake Up. As previously 
explained, Block and Wake Up are the vrimitives usei ty 
Supervisor precesses for interprocess communication. 


Blocx (figure 11) is called when a process 


Si 





Block Procedure 
Returns (Process ID Integer 
Message Message Tyne) 


Entry 
If APT [Process ID].Wakeup Waiting Switch - On 
Then APT EN o Usu AE ein "3 Off 
Else APT [Process ID].State :- Blocked 
Sched ready Process 


Fi 
process ID,Message := Get First Message(Message Queue) 


End Block 


emp 14. Block Srocednne 
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cannot continue until the occurrence of some other event. 
After going through the Gate Keeper, the call enters the 
Matic Controller. The Waxe Up Waiting Switch 15 
immediately checked. If the switch is on, the switch is 
reset to off, and the first message in the Message Queue 
Beine process is retrieved. The Traffic Controller then 
returns through the Gate Keeper. 

If the Wake Up Waiting Switch was off then the 
state of the process 1s set to Blocked. 
Ched heady Process is called to schedule the highest 
DAO yY ready Process on the virtual processor. In the 
Archival Storage System this is a trivial task, because 
me only other process which is loaded on the virtual 
processor is the idle process. The idle process can never 
block itself, so it must always be either running or 
Beady. In fact the idle precess will only consist cf 4 
Ext instruction. 

The acer le controller Gould nave been 
Mina psed into the Inner Traffic Controller for ta ds 
Mesien, but preservation of generality was a design goal. 
Later extensions will be easier to implement since the 
basic structure of the Traffic_Controller is present. 

The counterpart of Block 15 @axe Uo. Wake Jp 
(figure 15) is used by processes in the Supervisor dcmaic 
Wass messages to other processes in tne supervisor 
main. Upon entry into Waxe Up, the message is placed in 


the Message Queue of the awakened process. The 


O) 
(A 








Wake Up Procedure (Wakeup Process ID Integer 
Message Message Type) 
Returns (Success_Code Integer) 


Entry 
Do 
Success Code :- Insert Message(Wakeup Process ID Message) 
If Success Code = Queue Overflow 
mit Success Code = Not Allowed 
Then Exit 
Else APT [Wakeup Process ID].Wakeup_Waiting Switch := On 
If APT (Wakeup Process ID].State - Blocked 
Then APT (Wakeup Process ID].State := Ready 
Enter Ready Queue (Waxeup Process ID) 
Fi 
APT [Process ID].State = Ready 
Enter Ready QueueiProcess ID) 
Sched Ready Process 


Dt 
04 
End Wake Up 


Figure 15. Wake-up Procedure 
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Wake Up Yaiting Switch of the process to be awakened is 
men set to On. Then if the process state is blocked it is 
put into the Ready Queue and the State is set to ready. 
Regardless 0f the state of the awakened process, the 
waking process then puts itself into a Ready State and 
Enters the Ready Queue itself. This is necessary because 
mye process to be awakened may have a higher priority than 
RC valcins process. Every time either Block or Wake Up is 
called the scheduling algoritm İs executed 
(Sched Ready Process). 
C. Process Scheduling Algorithm 

Enter Ready Queue (figure 16) and 
mened Ready Process (figure 17) are two internal functions 
oe the Meee RG op troller. Eater Ready TOu2ueliS mused. ia 
ENGc)Hz a ready process into a first-in, first-out queue 
Een is organized by priority (fisure 12). The 
meaay Queue is designed as a two-dimensional array indexed 
Dyes Priority and a top and bottom pointer. The alzorithms 
for all queue operations are taken from Xnuth (21]. When a 
BCE AD 15 to be added to the queue the bottcm  poister 
more the appropriate priority queue is incremented ty one. 
Wine bottom pointer is at tne bottom of the linear array 
which implements the queue then it is set to the first 
Mocation of the array, thus wrapping around. The physical 
Beretn or each queue column is equal to tne total number 
of processes which can be entered into that queue at any 


EC in time so that the queue cannot overflow, The 





Enter Ready Queue Procedure (Process ID Integer) 


Entry 
If Ready Queue Bottom [APT [Process ID].Priority] - 


Max Queue Length 
Then Ready Queue Bottom (APT (Process ID].Priority] 


g 
Else Ready Queue Bottom [APT [Process ID].Priority] += 1 
l 


Ready_Queue [APT [Process_ID].Priority, Ready_Queue_Bottom] 
:= Process_ID 


nd Enter Ready Queue 


Cine To.” Enter Ready Queue Procedure 





Sched Ready Process Procedure 


Entry 
lori ty :z Max Priority 
Scan: Do 
If Ready Queue Top [Priority] = 
Ready Queue Bottom [Priority] 
Then Priority -= 1 
Bi PT yi < Min Priority 
Then Exit From Scan 
klse Repeat From Scan 
Fi 
Else If Ready Queue Top(Priority] = Max Queue Length 
Then Ready Queue TopiPriority] := 2 
Else Ready Queue Top[Priority] += 1 
Fi 
Run: If APT[Ready Process ID].Reqd Virt Processor 
z Processor ID 
Then APT [Ready Process ID].State := Running 
Inner TC (Swap MMU, Ready Process ID) 
Else Get Next Process(Ready Queue) 
nepeat From Run 
Fi 
Fi 
Od 


End Sched Ready Process 


Figure 17. Sched Ready Process Procedure 
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Priority ————————————5 
high low 


Top [Priority] —> 


Bottom [Priority] 


Figure 18. Ready Queue 
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meocess (0 às placed into the array at thé" locáfion 
pointed to by the bottom pointer. The queue is always 
entered at the logical bottom ard removal takes place from 
the logical top. 

The procedure which removes the processes from 
m op of the queue is Schéd Ready Process. The function 
of Sched Ready Process is to "pass" (as a baton in a relay 
Mice) the current virtual processor to the highest 
ENNOPLILty, ready process which can run on this specific 
etua] processor. Starting with the Max Priority queue, 
each queue is scanned until the first ready process that 
can run on the virtual processor currently erecuting in 
BENE Tie Controller is encountered. Sach aueue is 
tested in turn 26 determine if it is empty. If the queue 
me empty, then the next lower priority queue is scanned. 
The existence of an Idle process for each vismtua]l 
processor zuarantees that a ready process is always found, 
memeene Traffic Controller cannot exit without scheduling a 
Brocess, When a ready process is found, then the process 
State is set to running (scheduled) and tre 
Weni Traffic Controller is Called to aap MU. Ihis 


Era by will load the process descriptor segments ints 


14, 
ct 
Er 
(D 


(me Virtual Processor MMU, but in the desiga o 
#rchival Storage System the MMU of the Idle process is 
jdentical to the MMU of the loaded process. 


d. Message Queue Operators 
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The Message Queue (figure 
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Figure 19. Message Queue And Pointers 
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two-dimensional array of message frames . It is indexed 
in one dimension by the Process ID and in the other 
dimension by a top and bottom pointer. Insert Message 
(figure 20) is the primitive used by Wace Up to put a 
message into another process” message queue. The design 
only allows communication between processes of equal 
EEcurjty class since a Success Code is returned to the 
waking process. Get First Message (figure 21) is the 
primitive used by Block to retrieve messages from the 
message queve. If the queue is empty, tne message 
“Queue Empty is returned. 
Gr Non-Discretionary Security Module 

The key to implementing a particular 
memearseretionary security policy is in one module. .Ey 
representing the policy as a partially ordered lattice, an 
interpretation algorithm can be written to maxe a 
comparison between two labels and return a relationship. 
The relationship can be equal, less than, greater than, or 
not related, 

Me Non Discretiornary_Decurity Module shows iR 
meure 22 will determine the relationship of three 
categories of classification (Secret, Con idential, 
Unclassified). 4s shown there are no Checks for 
Compartments (e.g., crypto, nuclear, etc.). If a complete 
Bonssecurity policy interpretation is desired, the module 
can be expanded. Since some DOD specifications require 


aros tons for eight catezories and sixteea compartments, 
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Insert Message Procedure (Message Queue ID Integer 
Message Message Type) 
Returns (Success Code Integer) 


Entry 
If Non Disc Security (APTÍProcess ID].C1ass, 
APT[Message Queue ID].Class) = Equal 
Then 
If Message Queue Bottom[Message Queue ID] 
- Max Queue Length 
Then If Message Queue Top(Message Queue ID] = 2 
Then Success Code := Queue Overflow 
Else Message Queue Bottom[Message Queue ID] := 2 
Message Queue [Message Queue Id, 
Message Queue Bottom[Message Queue I2]] 
:= Message,Process ID 
puUcCcessmoode += Inserted 
nt 
Else If Message Queue Bottom[Message Queue ID] #1 
= Message Queue Top[Message Queue ID] 
Then Success Code :- Queue Overflow 
Else Message Queue Bottom[Message Queue ID] += 1 
Message Queue[Message Queue ID, 
Message Queue Bottom(Message Queue ID]] 
:- Message,Process ID 
Success Code :- Inserted 


Fi 
Fi 
Blse Success Code := Not Allowed 
Fi 


End insert Message 


Figure 29. Insert Message Procedure 
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Get First Message Procedure (Message Queue ID Integer) 
Returns (First Message Message Type) 


Entry 

If Message Queue Top[Message Queue ID] = 
Message Queue Bottom[Message Queue ID] 

Then First Message :- Queue Empty 

Else If Message Queue Top/Message Queue ID] = 

Max Queue Length 
Then a 
Else Message Queue ToplMessage Queue ID] + 
Fi 
First Message := Message Queue [Message Queue ID, 
Message Queue Top[Message Queue ID]] 


0 
ii 


E] 


End First Message 


Ba ine MAN Get First Message Procedure 
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Non Disc Security Procedure (Class 1 Longword 
Class 2 Longword) 
Returns (Relationship Integer) 


Entry 
m Class 1 
Case Unclassified Then 
er Glass 2 
Case Unclassified Then Relationship :-» Equal 
Case Confidential,Secret Then nelationship 
:5 Less Than 
Else Relationship := Not Related 
Fi 
Case Confidential Then 
If Class_2 
Case Unclassified Then Relationship := Greater_Than 
Case Confidential Then Pelationship := Equal 
Case Secret Then Relationship := Less_Than 
Else Relationship := Not_Related 
Pi 
Case Secret Then 
IMP gSs. 2 
Case Unclassified,Confidential Then 
Relationship := Greater Than 
Case Secret Then Relationship :-» Equal 
Else Relationship :- Not Related 
Fi 
Else Relationship := Not Related 


+ 


ri 


End Non Disc Security 


miiounes 22 Non DiscaSsecumity Procedure 
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a longword was chosen as the data type for representing 
the labels. The 32 bits of a longword are more than 
sufficient to represent all possible combinations of 
categories and compartments. 

Similarly, Privacy Act requirements are easily 
implemented in Non Discretionary Security since they cam 
be represented by a lattice “structure. Most other 
Meaevical non-discretionary security policies can be 
implemented as well. 

7. Inner Traffic Controller Module 

The Inner Lc Controler proves tne 
multiplexing of virtual processors to the real processor 
of the system. Zach loaded process will be allocated to a 
virtual processor, implying that there is a many to one 
correspondence. In ore cr to manage these virtual 
ENUSSSSoPS, the Inner Traffic Controller has direct" access 
to the machine hardware. The Memory Management Unit and 


Processor state are loaded and unloaded by the 


[3 
(D 


mer Traific Controller, thus accomplishing ti 
Dultiplexing to the physical processor. 

In addition to managinz the urinal 
ENOCSSSOPS, the Inner Traffije Controller furnishes 
inter-process services. Signal and Wait are used by 
BRacEeSsses im the Kernel ring to communicate with other 
Kernel Line processes and a re Pies of e 


mrererrarfic Controller. 


ct 
KY 
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Tha main database used to handle 
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miner Traffic Controller functions 15 the 
Virtual Processor Table. Additionally, a software image o? 
each MMU is maintained for every loaded process. 
a. Virtual Processor Table 

Cne Virtual Procescor Table (fikmre @5) Ys 
indexed by the Vintud leProcessor— 1D. Each virtual 
processor can be in one of three states: 1) Running, 2) 
Ready, or 3) Waiting. These three states are analogous to 
the state of a process and are used for processor 
Eunsdullns in the same manner as the Traffic Controller 
used the state of a process for scheduling processes. 
Movers the State field is the Signal Pending Switcna which 
WInGLLI0ONS precisely as the Wake Up Waiting Switcn for 
Meevenving a race condition from occurring with the 
er process communication primitives. Priority is the 
next field which is also analogous to the APT priority. 

Hoc rocessor State 15 a pointer to ae arza 


in memory where the MMU software image is maintained as 


meee as the "save block for the machine state o? the 
Arta l processor when it is ready or waiting. #igure 24 


is an example of the format of the MMU image. 
b. Kernel Interprocess Communication Prinitives 
Signal and Wait function in the same manner as 
Emocoes and azxe-=Uo. The chief distinction between i56 vairs 
aa leeree of trust placed on the correctness of use. 
inc Sienel and Wait are Kernel primitives which are usei 


Only by process operating in the Kernel domain, the call 


76 





ert 
meocessor_ 
ID 


Signal Loc. 
Pema reino rrority | Processor 





mnr eneo. Virtual Processori Tanlo 








imit iSize 
Attributes 


Mapping 
Register 1 





— am a— u ui comb 


Mapping 
Register 2 


Mapping 
Register 128 











[offset (how) 





Machine 
State 





Figure 24. MMU Image 
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can be guaranteed to return. The same trust cannot be 
placed on the calls to Block and Wake Up by processes in 
pne Supervisor ring. The loop free structure implies that 
the Kernel neither knows nor cares what happens in the 
outer domain for domains, if present). Yet, the Xernel 
must not allow the security state of the machine to change 
except in accordance with the rules of the mathematical 
model. 3lock 15 restricted to communication  amonz 
processes at the same level. The Kernel must call upon 
processes operating at different security levels to 
accomplish its task and thus needs a different primitive 
ENGE Systemwide information is being passed. 

With one exception, Signal {figure 25) and 
Wait (figure 26) function in the same manner as Wake Up 
End Block do in the Traffic Controller. Since the data 
gane tures in the Inner Traffic Controller function with 
uUa! processors, the Signaled Process IL or Process IL 
(input parameters) mus t be translated ino a 
Aena ted Processor ID or Processor ID. & one-dimensional 
table is maintained for this purpose. Because the 
mer Traffic Controller must complete its task before it 
returns to the calling procedure and is synchronous to the 
progress of the vrocess, the table translation of process 
martial processor works. The Idle processes will rever 
[ry to signal or Wait and will never cause the schedullaz 
algorithm to be executed. 


PS possible for the "lille ses 5 to RE 








Signal Procedure (Signaled Processor ID Integer 
Signal Message Message Type) 
Returns (Success Code Integer) 


Entry 
Do 
Signaled Processor ID := Map(Process ID) 
Success Code := Insert Message(Signaled Processor ID Message) 
If Success Code = Queue Overflow 
Orif Success Code = Not Allowed 
Then Exit 
Else VPT [Signaled Processor ID].Signal Pending Switch += On 
If VPT (Signaled Processor ID] .State = Waiting 
Then VPT [Signaled Processor ID].State :- Ready 
Enter Ready Queue (Signaled Processor ID) 


Fi 

V?T [Processor ID].State - Ready 
Enter Ready Queue(Processor ID) 
Sched Ready Processor 


Fi 
Od 
End Signal 


Fleure 25. Signal “Procedure 
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Wait Procedure 
Returns (Process ID Integer 
Signal Message Message Type) 


Entry 
Processor ID := Map(Process ID) 
If VPT [Processor ID].Signal Pending Switch = On 
Then VPT [Processor ID].Signal, Pending Switch := Off 
Else VPT (Processor ID].State :- Waiting 
; pened head Processor 
F 
Signal Message := Get First_Sig_Mess(Sig_Queue[Processor_ID]) 


End Wait 


Rigure 26. Wait Procedure 
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scheduled on each virtual processor in the storage system. 
When that occurs the real processor will come to a 
Biandstill, executing a Halt instruction. At first .glance 
Di would seem to be am error condition, but im reality 
me is not. since the Archival System is driven oy external 
events this may at times be a normal state. When a request: 
is made from a Host, the interrupt handler (an I/O Manager 
entry) will Signal (via the Inner Traffic Controller) the 
appropriate process and cause the scheduling algorithm to 
EN-ecuted. 
cae rise Functions 

PULI! of the functions of the 
WE raliie Controller are called from the Kerael ring. 
Ca ec. Delete See, Load, and Unload are service calls to 
support the Segment Manager. These are hardware dependent 
wage ons and the details of their design will be 
Nxenced by the specific characteristics of the MMU and 
min ar dware.,. Add Seg makes an entry into an MU hardware 
descriptor and also the MMU software image. This cell is 


Ee mrom Make “nown and will only set up tae descriptor. 


'cj 


Since the segment has not been Swapped In at this pcint, 
[he address fields of the descriptor Will be null and the 


Etr bute field of the descriptor will be set to inhibit 


La? Cru trom making access. 


Delete Seg is called fom  termibere and is 
required to remove an entry from the MMU and the software 


image. Load will vlace the absolute location of the 
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segment base address into the MMU and change the 
attributes to allow the CPU access. Unload removes the 
segment base address, inhibits CPU access again and also 
E leves the changed bit from the attribute field. This 
changed bit is set when a segment is written and is used 
By tne Memory Manager to decide if the segment can be 
overwritten or if it must be written back to secondary 
storage. A variant of Load and Unload is needed by the 
Memory Manager when doing a local to global move. 

Na MMU as called=trom the Tras ic Controller 
and is a result of the scheduling  algoribhmp. velas 
executed. In the general case a process swap would occur 
En. the virtual processor as a result of this call. In the 
Archival Storage System, there are only two processes 
which ere allowed to run ona virtual processor: 1) the 
loaded process or 2) the Idle process. 4n MMU swap will 
Sori occur conceptually when the idle process is loaded 
because it has an MMU imaze just as any other process. 
Actually the idle process’s MMU image is exactly the same 
as the loaded process, so a physical swap does not tare 


place. 


Other service calls will be made to tae 
Inner Traffic Controller from the Memory Manager amd 
I/C_ Manager but are not detailed here. Software faults, as 
discussed in O’Connell and Richardson [5], are net needed 
ies design. 


8. “Memory Manager Module 








The Memory Manager is a non-distributed Kernel 
process and is responsible for managing the real memory 
resources of the system. The real memory of the system is 
both main memory (random access) and secondary storage 
(non-random access). The Memory Manager could be part of 
the distributed Kernel in the Archival Storaze System 
since it 1s designed for a single microprocessor; however, 
the process abstraction is used to maintain the family 
member character of the design. 

a. Memory Management Scheme 

The two main tasks of the Memory_Manager are 
to bring segments into memory (In) or remove segments from 
memory (Out). Partitioned allocation is tne scheme 
employed to manage the memory resource. Zach loaded 
process is given a partition of linear contiguous real 
core and is required to manage (via calls to Swap In and 
EXUNOUt) the partition (its linear virtual core) ja any 
way it chooses. The Memory Manager checks each ‘Ir 
request against the process's allocation to insure that 
the allocation is not exceeded and to insure thar 
previously allocated memory is not overlayed. 

When a shared segment is not writeabie (i.e., 
Write permission has not teen given to amy process), the 
design allows multiple copies (one per process) of tke 
segment to exist. This frees the Memory_Manager from the 
task of moving the segnent to “processor global” memory, 


requesting that all MMU images be undated, and reserves 








global memory for segments which are shared and writeable. 
Furthermore, the space that can be saved by having one 
copy would not be usable by the processes which are 
sharing the segment, since each process 's Supervisor would 
still have the segment in its virtual core. 

If a segment is to be shared and is writeable, 
then the Memory Manager must move it to global memory [5]. 
This insures that all users are sharing the same 
information. Again, the actual location of the segment is 
invisible to the sharing processes. More memory 15 
allocated to the segment than it actually uses: viz., one 
copy per sharing process. However, the alternative to 
using memory is a complex algorithm for dynamically 
reconfiguring the mapping of each partition whenever a 
shared segment is relocated in memory. The tradeoff of 
memory size for complerity is indicated in this 
application. Segments are placed in memory within tne 
appropriate vartition at the location specified by the 
Supervisor call to Swap In. A simple bit map known as the 
Memory Allocation Map (figure 27) is used to indicate 
which parts of memory are available for use. Each bit of 
Ene map corresponds to a 256-byte page of memory. The term 
page is not used here in the classical sense, but is used 
to indicate a block of physical memory. Segments cannot be 
Mu dedo into pages scattered through core, bu: must be 
allocated to contiguous memory locations. 


The primary database of the Memory Manager is 








Memory Bit Map 
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Figure 27. Memory Allocation Map 
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the Active Segment Table. It provides the Memory Manager 
with the information necessary for managing all segments 
in the system which are active. 
b. Active Segment Table 
There are two sections of the 
[ive Segment Table (AST). That portion of the AST which 


contains systemwide information is known as the 


ct 


Global Active Segment Table (G AST). Every activa segmen 


a voe system will have an entry in the GAST. 


I 


A 
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KY 


Memory Manager also maintains a portion of the AST pe 
physical processor as the Local Active Segment Table 
(L AST). Only those segments active within the physical 
processor will te in the L AST. 

When a segment is Made Znown it becomes 
active and will have an entry in the G AST (figure 28) and 
Eene appropriate L AST (figure 29). The concateration of 
the segment ’s Uniaue_ID and the index to the segment ss 


entry in the G_AST form the ASTS # which is the handle” 
passed by the Memory Manager for identifying e specific 
active segment. When the Memory Manager uses the handle. 
to enter the G AST, it uses the Entry * of the ASIE 2 
portion as the index. In the general case (e.g., demand 
activation/deactivation), the Unique_ID of the “handle is 
nen compared with the Unique ID found in the G SST entry. 
Ene identiticatlon check results 12 a mismatch, the 


G AST must be searched using the Unique ID as a xey to 


eds the correct entry. This procedure is necessary 





—ASTE $ 


LOCK 
Unique | Global | Connected |written | write- !Alias 4 [Page | 
ID Addr Processors BINE able Table jEntries |Table 


Bit ASTE Mm Active] Addr 


Fizure 28. Global Active Segment Table 


Segment | 
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rigure 29. Local #ctive Segment Table 
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because it is possible that a segment ’s entry could be 
moved in the G AST before all processes could be notified 
Ut the new ASTE #. If this occurred and a check was not 
made, an unauthorized access could then take place. If the 
Match is successful when first checked, the prover entry 
has been found. In this design all known segments for all 
processes are active so this problem cannot occur. 

Since the G AST is a systemwide Tesource a 
lock must be used on the G AST to prevent a race condition 
from occurring [11]. The mechanism used in the design is a 
Mecked/unlocked flag. Synchronization on the lock is 
inherent in the functioning of the Memory Manager Ss 
Signal Message Queue. Note that this mechanism will not 
work if the design is extended to include more than one 
processor in tne system Sharing the single G_AST. 

Pic lobal Address field is used orly ine 
segment is located in global memory. If it is null the 
address can be found in the L AST. The Connected Processes 
meld "Ys a bit map signifyina whicn processes curreatly 
have the segment active. 

The Written flag is used to retain a written 
bit when a process Swaps Out a segment whicn is snared and 


WIL e able.” For example: Processes à and 5 are sherine a 


cr 


an 
-— bh 


segment and Process A has write permission. A has writ 


in the segment and now wants to deactivate the segment. 
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Process B is still using the segment. When A requests ta 


(D 


Deactivate, the Written bat 1s passed tie th 





Memory Manager. But since B continues to use the segment, 
the Memory Manager will only reset Process A“s Tlas in thé 
Bonuected Process field. ThemWritten bit is then lowicallg 
ORed with the G_AST_Written Flag. When B then Deactivates 
EEsesment, the Written bit it passes indicates that a 
write has not taken place. An error would have occurred if 
the Written bit from Process A had not been saved since 
the Memory Manager does not write an unmodified segment 
back to secondary storage. 

The Writeable flag is set whenever any process 
has write access to the segment. This is the key flag for 
deciding (at the time activation is requested) if the 
segment must be placed in global memory. It cannot 
conveniently be used to provide an alternative to the 
scenario presented above for Written. Consider that 
Processes A, B, and C all bave writeable shared access. I? 
MEaDesctilvates after writing, the Memory Manager could 
write back to secondary storage at that time, (assuming 
Breeproper synchronization was used to prevent 3 or € From 
writing while the transfer took place). Then when 3 or C 
Deactivated after writing, anotner write to secondary 
storage would take place. Thus at least one unnecessary 
meron took place. 

The Alias Table ASTE 8 will be null unless the 
segment is a mentor segment. Whenever a mentor segmert is 
made active its Alias Tatle segment is made active at the 


same time and will be assigned an ASTE 2. (The Alias Table 





is a Memory Manager object. The Alias-Table is actually 
implemented as a collection of segments.) 

In the seneral case we Uh demand 
activation/deactivation, the 4 Entries Active is a field 
mortem is used for Alias Table entries only. An Alias Table 
segment must remain active as long as any of its entries 
are active, although it need not remain in main memory. 
The # Entries Active ls a counter which is incremented any 
time an Alias Table Entry is activated and decremented 
when am aPAlias Table Entry is deactivated. Thus the 
Heras Table frame can be deactivated only when tae 
Connected Processor map of the mentor segment and the 
# Entries Active both become zero or null. (Note that the 
memmectea Processor Map of the Alias Table segment yill 
always show only the physical processors “nose 
Memory Manager has the Alias Table in its address space.) 
metos design all known segments are active so these 
erplicit checks upon deactivation are not required. 

The remaining field of the G AST is the 
Page Table Address. The Page Table Address is the locatlon 
in secondary storage of the page table. The page table in 
En provides the location of the segment. 

DEG LONST portPon of UUbBsWwEoUER' S maha anane a er 
physical processor and should not be confused with a 
distributed data structure since the LAST is a 
Memory Manager data structure and not pari om the 


distributed Kernel. It is searched by Virtual Processor I2 
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and segment Unique ID. The remaining four fields are 
Access, Absolute Address, Size, and Segment #. The Access 
is the read or read/write access of the segment available 
for use in moving between local and global memory. The 
Absolute Address is the location of the segment in main 
memory. If Absolute Address is null, the segment is on 
secondary storage and has not been moved to main memory. 
©. Aliasing Scheme 

The Memory_Manager also provides the aliasing 
service for the system. Hach segment which exists in the 
Archival Storage System has a Unique ID. This Unique ID is 
an integer which uniauely identifies each segment. It is 
chosen from a large list of integers. Since the data type 
ena loneword, the list contains more than four billion 
unique integers. To prevent a communication path from 
existing when a segment identification must be passed out 
of the Kernel, an alias is provided which virtualizes the 
Musique ID. When a process wishes to create a new segment, 
it must Pass the Kernel a Mentor Segment # and a desired 
ED ira. The mentor segment can be any segment the 
Supervisor wishes, but an entry for the mentor must be in 
the Known Segment Table of Ube process. The 
Segment Manager then looks up the ASTE * of the segment 
and Signals the Memory Manager with the ASTE_# and 
Env #. The Memory Manager maintains a “lat file system 
known as the Alias Table (figure 30) which is systemwide. 


Every active mentor segment has an ASTE s for a segment of 
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Figure 30. Alias Table 








the Alias Table. When the Memory Manager receives a Signal 
which requires use of the Alias Table, the Memory Manager 
brings the appropriate Alias Table segment into memory. 
Ihe Entry # is then used as an index into the Alias Table 
where the Memory Manager can determine the Unique ID and 
physical attributes of the indexed segment. A segment 
exists for each entry in the A 

The attributes found in the Alias Table are 
the segment Size, “the location of its secondary storage 
Page Table, the segment Access Class, and the secondary 
storage page table of its Alias Table segment if it is a 
mentor sezment. Alias Table storage is allocatedewhea the 
first request for an Alias Table entry is made, and is 
deallocated whenever the segment is empty. The 
Non Manager will not honor a request to delete a 
segment if it has an Alias Table segment. If? this deletion 
were allowed, storage space would be lost forever since 
the Alias Table segment of the mentor segment and any 
segments referred to by that Alias Table segment would not 
be recovered. 

d. Storage Allocatior 

me Memory_Manager is responsible POT 
comtrollirs storage media as well as"main memory. The 
J omase hardware for this d@siga is anticloqved™ Lo be a 
type cf hard disk using the «Winchester technology. 
However, the design may be initially implemented on an 


eight-inch “floppy” disk drive using the IBM standard, 
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Eingle" density format. Using this standard, a single. disk 
has 77 tracks of 26 sectors each available for storage. 
zach sector stores 128 bytes of information. 

Since the 28020 hardware allows segment sizes 
si multiples of 256 bytes, it is convenient to establish a 
“page” size as 256 bytes. Using this scheme, a page can 
Cena pe stored in two sectors of the disk. A page then 
becomes convenient as the size of a page table. The page 
Nets used to record the location of each page o? the 
segment on the disk. If the location of each page is 
Seored in unvacked form, a total of 128 page locations can 
be stored in a page. Note, however, that this scheme uses 
Ea 11 of the 16 bits which can contain information (7 
bits for the track index, and 4 for the sector index), and 
can easily be reduced to 12 bits since “every other sector 
is not explicitly indexed. This means that 1024 pages can 
be addressed by one page of a Page Table and is adequate 
to store the maximum size segment (256 pages) allowed by 
the 289020 hardware. 

À free page bit map is needed in order to 
record which pazes on the disk are available and which are 
allocated. This will also require one page on the disk. 
This scheme allows the disk space to be allocated to 
segments from the “free list” and does not require complex 
compaction aleorithms. If other forms of storage media are 
used they can be easily adapted to this scheme. 


9. Input Output Manager Module 
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The 1/C Manager is the non-distributed Kernel 
process which is concerned with moving information across 
the boundaries of the Archival Storage System. It manages 
the input and output ports of the system as a resource in 
much the same way as the Memory Manager handled the memory 
resource, The I/O Manager would use an Attach Table to 
virtualize the system ports. While the I/O Manager is a 
process in the general case, it can be designed and 


implemerted as a distributed Kernel function. 








III. CONCLUSION AND FOLLOW ON WORK 


The detailed design of the Security Kernel for a data 
warehouse has teen presented. This design is suitable for 
implementation on a Zilog 22008 microprocessor-based 
system. A minimal subset of a family of secure operatinz 
systems has been demonstrated to exist and can be 
implemented on microprocessor hardware whicn is available 
today. This design also shows the feasibility of an 
Archival Storage System that can be the nucleus of a 
sa etributed, multi-microvrocessor computer system by 
Providing archival storage with multilevel security. 

The design illustrates the utility of modern software 
engineering techniques. A loop-free Structure was 
maintained as a design goal, preserving the atility to 
modify a module without introducing change in any other 
nodules. An explicit process structure simplifies the 
MENS for asynchronous functions. Functionality of” this 
family member can be extended by including additional 
emi ives from the larger set of primitives described by 
O Connell and Richardson [5!. 

Security of information was a primary goal throughout 
the design process. A mathematical model was used as a 
foundation for the Kernel to insure properly designec 
Security. b multilevel security capability is included fol 
the storage system. Furthermore, on this base a complete, 
multilevel secure, distributed "system can be constructed 


with the storage system as the only component requirinz 


om 





multilevel security. 

While designed for a single microprocessor with memory 
management unit support, the structure of the high level 
design which allows configuration independence was 
me erved. The same concepts for reducing bus contemtion 
in a Multiprocessor system while providing data sharing 
were used and can be easily extended, e.g., for increased 
processing capacity to serve a large number of higher 
bandwidth hosts. 

Implementation of the Archival Storage System is an 
area for further work. The distributed Xernel data 
structures and procedures are described in this thesis. 
Additional effort will produce compilable implementation 
code and from this code generate a loadable system. The 
Kernel nor-distributed processes for I/O and physical 
memory management have been briefly presented and more 
detailed design will be needed prior to implementation. 
The Archival Storage System design is a minimal family 
member. AO nal services to the Supervisor and 
gzeneralization of the simplifying assumptions (2. 3., to 
interface to multilevel hosts) are major areas where 
continued research is indicated. 

After imolementation of the storage system, 
Substantial work is necessary in performance evaluation. 
Hardware choices have been primarily leat to the 


d 


implementor. Since man y 0% the software d 
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sign 
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implications on efficiency are unknown at tne presen 








time, fine-tuning of both hardware and software will 


result in better system performance. 








APPENDIX A - GATE KEEPER LISTING 


Gate Keeper Procedure 


Type 
Parameter Table Entry Record [Function Address Longword 
NO Of Parameters Longer 
Para 1 Length Integer 
Parad 2 Lengin Integer 


Para n Length Integer] 


Local Ninatializ7e local varianias! 
Valid :=1 
Invalid := 0 
Index := 8 


Parameter Table Array [Max_Function_Code 
Parameter Table Entry] 

e=[ [<<Traffic Controller>>Elock „autty, x 
[<<Traffic Controller>>Yaxe Up Entry,3)], 
[<<Segment Manager>>Create_ silo 
[<<Segment Manager>>Delete_ Entry, ar, 
[<<Segment Manager>>Make Xrown Zntry,5], 
[<<Segment Manager>»>»Terminate_3ntry, E 
[<<Segrent_Manager>>Swep_In satry,3]. 
[<<Segment Manager>>Swap Out _Entry,2]] 
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Entry 

DI NVI,VI [Disable interrupts! 

PUSH QRR14,R0 {Save user registers! 

PUSH @RR14,R1 

PUSH QGRR14,R2 

PUSH GRR14,R35 

PUSH @RR14,R4 

PUSH @2R14,R5 

PUSH QGRR14,R6 

PUSH GRR14,R7 

PUSH GR314,R8 

PUSE GRR14,R9 

PUSH @RR14,R12 

PUSE @RR14,R11 

PUSH QGRR14,R12 

PUSH @RR14,213 

imei R2,NSPSEG Save user stack pointer! 

LDCTL R3,NSPOFF 

PUSH @RR14,22 

PUSE #@R214,R3 

El NVI,VI maples Interrupts ! 

VALIDATE: DO Scheck location of arguments for user 

read/write access! 
LOL <<DIST_KERNEL ID>>ARGUMENT POINTER,RR2 
CALL CHECK ADDRESS SPACE 
[Get return value! 
LD GRE <CDIST KERNEL IDD VALIDITY CODE 
Oe AE 
CPE NAL RES 
IRON VALIDATES Return if invalid! 
ELCO R DL RREZ, << DIST KERNEL ID) ARGUMENT POINTER 
COS IRA INDEX 
I 
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MOVE STACK: DO ¡Move argument list to Kernel work space! 
CPB RHO 80 
IF EQ TEEN POP R4,@RR2 
PUSH @RR14,R4 
DºC RHO 
ELSE EXIT FEOM MOVE STACK 
FI 
REPEAT FROM MOVE STACK [Loop until all moved! 
OD 
CALC FUNCTION: DO 
LD FUNCTION CODE ,@RR14(#24) lRetrieved from system call 
instruction on system stack! 
RG AA FUNCTION CODE 
CP R6,FUNCTICN CODE 
MET THEN LD LDL RR10, KDIST KERNEL IDDOMESS1GE POINTEE 
LD R2,INVALID FUNCTION CODE 
LD @RR12(0),R2 (Put error code into message! 
EXIT FROM CALL FUNCTION 
ELSE LD R6,GRR2(NUMBFR OF ARGUMENTS) 
[Check number of parameters! 
B RE,FUNCTION TAB BLE [FUNCTION COD*,NO OF ARGUMENTS] 
EQ TZZN CALL FUNCTION TABLE [FUNCTION CODE, FUNCTION] 
ELSE LDL RR13,<<DIST KERNEL ID>>M3 SSAGE POINTER 
DD INVALID ARGUMENT LIST 
LD CRR19(0), RZ 
EXIT FROM CALL FUNCTION 
"I 
FI 
OD ¡END OF CALL FUNCTION LOOP! 
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LDB RAL, INDEX 'Zero out user argument list! 
ZERO OUT: DO 


CP RH1,#@ 

IF NE TEEN POP R2,@RR14 
DEC 2H1 

ELSE EXIT FROM ZERO_OUT 

FI 

REPEAT 

OD 


LDL RR8,<<DIST_ KERNEL ID>>MESSAGE POINTER 
LDL 2R4,@RR14(NSTACK POINTER) 


LDB RH2,*€ 
LDB RH1,49 
MOVE RET MSG: DO [Put message back in user area! 
CP FH1,4#0 
IF NE THEN LD R2,CRRE( RH6) 
PUSH @RR4,R2 
INC RH2 
DEC REIl 
ELSE EXIT FROM MOVE RET MSG 
FI 
RSA T 
OD 
OD {END OF VALIDATE! 
DI NMI,VI IDisable interrupts! 
POP R3,@RR14 'Restore user registers! 
POER CRRI 
LDCTL NSPSEG,RS 
BUGIL NSGPO0OT? ,322 
POP HALO, CRETA 
POP R12,QRR14 
POP R11,GRR14 
POP R10.@RF14 
POP R9,GRR14 
POP RE told 
POP R7,GR214 
POP RE,CRR14 
PDOP no Tera A 
POP E4,GRR14 
POP R3,QRR14 
POP R2,GR8IA4 
POP R1,CRR14 
POP R9,@RR14 
BI NMI,VI [Enable interrupts! 
rt 'Restore pre-call cpu state! 


Emo Gate Keeper 
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APPENDIX B - SUCCESS AND ERROR CODES 


CODE 


Mivagiid Function Code 
Invalid Argument Code 


Mentor Seg Not Found 


Not Allowed 


Not Compatible 
Segment Too Large 
No Segment # Avail 


Segment Found 


Segment Not Known 
Segment In Core 
Eel segment 
Invalid Segment # 
Swapped In 
Swapped Cut 

Queue Empty 

Queue Overflow 


Inserted 


ONERI POINT 


Gate Keeper 
Gabegkeeper 
Create Segment 
Delete Segment 
Create Segment 
Delete Segment 
Make Known 
Wake Up 

Create Segment 
Create semen 
Maxe Known 
Make Xnown 
Swap In 

Swap Out 
Terminate 
Terminate 
Terminate 
Terminate 

Swap In 

Swap Out 

BOC 

Wake_Up 


Wake Up 
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CODE ENTRY POINT 


uat Related Non ScEDCONMNUT 
Greater Than Non Disce Secunity 
Less_Than NON "DISC Security 
Equal Non- DIS Security 
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